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METHODS FOR FACILITATING VALIDATION OF FINANCIAL 
TRANSACTIONS MADE THROUGH A WIRELESS 
COMMUNICATION NETWORK 

TECHNICAL FIELD 

The invention relates to wireless telecommunication systems, and 
more particularly to systems which enables to make financial 
transactions through a wireless communication network. 

BACKGROUND OF THE INVENTION 

In the recent years digital wireless communication networks (GSr«1, 
CDMA) have enjoyed a great success, and have provided users with 
a range of new possibilities. New generations of networks like 
WCDMA, CDMA 2000, or TD-SCDMA which are starting to be 
deployed will be able offer many more capabilities to the users like 
video streaming etc... Digital mobile phones are also having more 
impressive features, increased processing power and memory and 
could be used for a wide range of applications, going far beyond 
voice, text communication or data transfer. 

Despite all those capabilities of the networks or of the mobile 
phones, some applications like the ability to make payments 
through wireless communication network and with mobile phones 
have not emerged, and few attempts have proved to be too 
complex to implement. 

This invention refers also to a previous patent application 
PCT/CN02/O03O1, describing a ^'SYSTEM TO ENABLE A TELECOM 
OPERATOR PROVIDE FINANCIAL TRANSACTIONS SERVICES AND 
METHODS FOR IMPLEMENTING SUCH TRANSACTIONS''. 
The above mentioned patent application brings some solutions to 
the issue of executing financial transactions through wireless 
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communication network and describes several methods for 
executing payment among which: 

- Simple Payment 

- Payment Request 

In the Simple Payment transaction process, the payment is 
executed immediately upon receipt by the Transaction Processing 
platform, and the execution is notified to both parties, the Payer and 
the Payee. In some circumstances this could create a problem if the 
Payer is ill intentioned and the Payee is not willing to receive such 
payment. The present invention Is bringing a solution to this 
potential problem. 

In the Payment Request the Payee needs to know the Payer's 
account number in order to be able to send the Payment Request. 
This number is generally a 8 to 16 digit one and Its manual capture 
may be uneasy or even a source of unwanted errors. The present 
Invention Is bringing a solution to this situation. Also, when the 
Payer receives a Payment Request from a Payee, the Payee's 
account number is displayed. In some circumstances It might not be 
easy, fast enough or comfortable for the Payer to identify or 
recognise the Payee just by his account number. The present 
invention Is bringing a solution to this situation. 

SUMMARY OF THE INVENTION 

The object of the present invention Is to bring innovative 
improvements to the methods already described in the patent 
application PCT/CN02/00301, for the validation and execution of the 
financial transactions. 

According to the Invention, a request for approval Is introduced and 
sent to the Payee, In a Simple Payment scenario, for him/her to 
decide to receive or not a payment on his/her Financial Transaction 
Account. 



According to the Invention a subscriber to the Financial Transaction 
Service, has the ability to set up Special Lists of Financial 
Transaction Accounts which are submitted to Particular Rules be 
applied when such accounts are Involved in transactions with the 
subscriber's own account. According to the Invention such particular 
rules are checked and Implemented by the Transaction Processing 
Platform and/or by the mobile handset and/or the SIM of said 
subscriber. According to the Invention the said Special Lists are 
stored in part or Integrally In files connected to the Transaction 
Processing Platform and/or In a memory of the mobile handset and 
or In a memory of the SIM. 

According to the invention, the Financial Transaction Account 
number of a subscriber can be read automatically by another 
subscriber by methods and means which are described In the 
Invention. 

According to the Invention, the validation of a Payment Request that 
Is sent to a Payer for approval, is facilitated by the display on his 
mobile handset of the Payee's name or logo or an easily 
recognisable sign or an audible message. 

BRIEF DESCRIPTION OF DRAWINGS 

The Invention will be described more In detail below with reference 
to the appended drawings, in which: 

Figure 1 Is a representation of the process involved between the 
Payer, the Transaction Processing Platform and the Payee for a 
Simple Payment with a request for approval submitted to the Payee 
Figure 2 is an example of few representations of displays appearing 
on screens of mobile handset of the Payee or the Payer during some 
of the steps of Simple Payment process described In Figure 1. 
Figure 3 Is an example of representation of the Financial Transaction 
Account (FTA) number printed in clear and in barcode format, 



affixed on the back side of a mobile handset. 

Figure 4 is an example of representations of different ways to 
display the Payee (a famous supermarket chain) number, name and 
logo on a Payment request sent to a Payer. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

In the patent application PCT/CN02/00301, two transaction 
scenarios and their respective process are described In great details; 
they are: 

- Scenario 1: Simple payment 

- Scenario 2: Payment request 

Those two scenarios represent the most frequently used financial 
transaction scenarios. 

The present invention brings additional Innovative features and 
improvements to those processes, which are further described 
below. 

Scenario 1: Simple payment 
This scenario Is typical of a peer to peer transaction where Payer ''B" 
sends a payment to Payee ''A". Although it might not be usual, it 
may happen that on some occasions ''A" is not willing to receive a 
certain sum of money from an unknown Payer In this case ''B". 
In such case, needs to have the possibility to reject an 
unwanted payment. 

According to the invention, a step Is Included In the transaction 
process where by the Payee '"A" Is requested to approve or reject 
the payment on his/her Financial Transaction Account (FTA) sent by 
the Payer '*B'' (see Figure 1). In one of the embodiment of the 
Invention the Transaction Processing platform (TPP) sends to the 
Payee's mobile phone or connectable electronic device, an approval 
request which, as an example, can have the following content (see 
Figure 2a) : 



Do you accept this payment to you account? 

Amount: 168.00$ 

From Payer N^: 8653 2543 5555 

Object: your book 

Comments: thanks 
The Payee '"A" is hence requested to answer YES or NO by pressing 
the corresponding key. Once the Payee ''A" has pressed the key of 
his choice, he is prompted to Confirm/Validate/Sign by imputing his 
Password (see Figure N^2b) or by any of the other mean as 
described in the referred patent application PCT/CN02/00301. 
According to the Invention, the Mobile Transaction Management 
Software (MTMS), installed on the mobile handset or connectable 
electronic device or the SIM, Is then generating a data file with the 
data of the proposed transaction, the Date & Time, the decision of 
the Payee '^A" (I.e. approval or rejection), and the corresponding 
digital signature. This data file Is then encrypted and sent to the TPP 
for execution. 

Upon receipt of the Payee decision, TPP will execute the 
transaction according to Payee's choice: 

- In case of approval payment Is executed In favour of ""A", with the 
process described In patent application PCT/CN02/00301 

- In case of rejection, TPP will send a rejection notification to the 
Payer ""B" which can have the following content (see Figure 2c): 

YOUR PAYMENT OF 

Amount $: 168.00 

To Payee N^: 8658 1235 7777 

HAS BEEN REJECTEDl 
This method Is particularly Interesting to protect people against III 
Intentloned financial transactions attempts (corruption, blackmail, 
etc.); however in some cases the need for approving a payment 
receipt might not be Justified or might even be annoying. This would 



be the case for example when payees are expecting the payment to 
arrive from known payers (relatives, friends, customers, etc.). 
In such case It Is useful that the system be able to identify and 
distinguish transactions coming from accepted, unknown, or 
unwanted payers. According to such distinction the system will send 
or not a request for approval to the payee or even reject the 
transaction. 

According to the invention, the system described in the patent 
application PCT/CN02/00301, provides the subscribers to the 
financial transaction service with the possibility of including in a 
Special List FTA numbers for which request for approval shall not be 
required. 

But the notion of Special List can be further extended to other types 
of rules to bring additional advantages In controlling or validating 
transactions. A rule or a set of rules can be selected to define a 
Special List for a subscriber. Those rules are applied to the 
transactions between the subscriber (owner of the Special List) and 
the accounts Included in the Special List. A subscriber can have one 
or several Special lists. In one embodiment of the invention the 
rules are checked and applied by the Transaction Processing 
Platform. In another embodiment of the Invention the rules are 
checked and applied by the MTMS running on the mobile handset or 
on the SIM. 

As examples, the following Special Lists are defined with their 

corresponding rules: 

Default List: No particular rule 

By default all accounts are Included in the Default List. For 

those accounts no particular rule is applied. 
Green List: No request for approval required 

If a subscriber Includes some accounts in his/her Green List, 

then Simple Payment received from those accounts shall NOT 



require any request for approval (as described above) to be 
sent to the payee. The Simple Payment will be executed and 
notified to the parties as described in patent application 
PCT/CN02/00301. 

Black List: All transactions rejected 

If a subscriber includes some accounts in his/her Black List, 
then no transaction is possible with those accounts. 

Red List: Receiving Simple Payment rejected only 

If a subscriber includes some accounts in his/her Red List, then 
only Simple Payment coming from those accounts shall be 
rejected by the TPP without notifying the subscriber; however 
other types of transactions shall be possible with those 
accounts. 

Orange List: Sending Simple Payment rejected only 

If a subscriber includes some accounts In his/her Orange List, 
then he/she shall not be able to send Simple Payment to those 
accounts; however other types of transactions shall be possible 
with those accounts. 
Blue List: No payment request accepted 

If a subscriber includes some accounts in his/her Blue List, then 
Payment Request coming from those accounts shall be rejected 
by the TPP without notifying the subscriber; however other 
types of transactions shall be possible with those accounts. 
The names of the lists are just given as examples. 
It Is also easily understandable that several other kinds of Special 
Lists may be created with a particular rule for a certain purpose. For 
example some lists might be created with the purpose of setting 
certain limited amounts in transactions with the accounts of the said 
list. 

According to the invention, any subscriber to the Financial 
Transaction Service has the possibility to update (I.e. add and/or 
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remove accounts) his/her Special Lists directly from his/her mobile 
handset or connectable electronic device. 

According to the Invention, a subscriber has the possibility to insert 
ALL existing Financial Transaction Accounts In a Special Ust. By 
doing so and then by having the possibility to remove a few ones 
among all, this provides a high degree of flexibility which can be 
easily understood. For example a father can have his child enrolled 
to the Financial Transaction Service and ask to have ALL accounts to 
be put In the Black List of his child, then he can remove some 
accounts from the Black List; as such the child will be able to make 
transactions only with a limited number of approved accounts. 
The benefits of having such Special Lists available are easy to 
understand. For example a retailer whose preoccupation would be to 
speed up the payment process at his point of sale, and also to 
prevent the staff from making payments will put all FTA in Green 
List, in Orange List and in Blue List. 

According to the invention, the various Special Lists mentioned 
above are at least stored In a database, or in dedicated files 
managed by, or Interfaced with, the Transaction Processing Platform 
(TPP). 

In another embodiment of the invention the Special Lists are also 
stored totally or In part In a memory of the mobile handset, or the 
connectable electronic device and/or In a memory of the Subscriber 
Identity Module (SIM, USIM, UIM or equivalent). 

Scenario 2: Payment Request 
In this scenario, the Payee '^A'' Is the initiator of the transaction 
when he/she sends a Payment Request to the Payer "^B". This 
scenario Is particularly suitable in a retail environment, as it allows 
the retailer, for example, to send the transaction data to the 
customer and thus does not require the customer to key in the data 
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to be able to make the payment. However this process requires the 
payee to capture and l<ey In the payer's FTA number. FTA numbers 
have generally several digits (usually 8 to 16) and capturing, then 
keying in such account number can be a lengthy process as well as 
prone to unnoticeable errors; and capturing automatically the 
payer's FTA number shall bring great benefits. 
According to the invention, the Payer's FTA number is stored in/on 
the Payer's handset In a form that can be read and captured by an 
automatic reading device connected to the mobile handset or the 
connectable electronic device of the Payee. 

In one embodiment of the invention the Payer's FTA number is 
printed In barcode format on a sticker affixed on the back of the 
mobile handset (see Rgure 3). In this case, the Payee who has a 
barcode reader connected to his/her mobile handset or connectable 
electronic device, has just to get close to the Payer's mobile handset 
with the barcode reader and capture the Payer's FTA number. The 
Payee can then continue preparing the payment request as 
described in patent application PCT/CN02/00301. 
In other embodiment of the Invention, the FTA number Is printed in 
a barcode format on a card that Is presented to ttie Payee to be 
read automatically. 

In another embodiment of the Invention the FTA number is stored In 
ttie memory of a contactless electronic chip, which Is affixed 
somewhere on or In the Payer's mobile handset or connectable 
electronic device. Such contactless chip can be read from a distance 
(generally several centimetres), through electromagnetic waves, by 
an adequate contactless reader which is connected to the mobile 
handset or connectable electronic device of the Payee. 
In another embodiment of the Invention the FTA number is stored In 
the memory of the SIM which has a contactless Interface, and can 
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be read by an adequate contactless reader which is connected to the 
mobile handset or connectable electronic device of the Payee. 
In another embodiment of the invention the FTA number Is read 
from the memory of the Payer's mobile handset or from the 
memory of the Payer's SIM, and sent through the Infra Red port of 
said handset to the Infra Red port of the payee's mobile handset or 
connectable electronic device. 

In another embodiment of the invention the FTA number is read 
from the memory of the Payer's mobile handset or from the 
memory of the Payer's SIM, and sent through a short range radio 
interface (like BlueTooth, WIFI, or other) to the mobile handset or 
connectable electronic device of the Payee. 

In the transaction process described in the patent application 
PCT/CN02/00301, when a Payer receives a Payment Request, the 
Payee Is identified only by his FTA number (see Figure 4a). In some 
circumstances this might induce some discomfort for the Payer as 
he/she must verify that this number matches with the one of the 
retailer. Further more, some people might try to use a lack of 
vigilance from the part of the Payer . In verifying the retailer's FTA 
number, to send at the same moment another Payment Request to 
the same Payer In an attempt to get paid before the retailer's 
Payment Request is actually accepted. The Invention brings a 
solution to such potential problem characterised in that when TPP Is 
sending the Payment Request to the Payee, it will add a data that 
will be displayed in lieu of the Payee FTA number. 
According to the invention, the said data display Is easily or quickly 
recognisable by the Payer. 

In one embodiment of the invention the said data display is the 
name or the brand of the Payee (see Figure 4b). 
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In another embodiment of the invention the said data display is an 
image, a logo, an icon, or any other easily recognisable graphical 
mark (see Figure 4c) 

In another embodiment of the invention an audible message 
enabling to recognise easily the Payee Is emitted by the Payer's 
mobile handset while the Payer is looking at the Payment Request. 

The Invention being thus described, it will be obvious that the same 
way be varied In many ways. Such variations are not to be regarded 
as a departure from the scope of the Invention, and all such 
modifications as would be obvious to a person skilled In the art are 
intended to be included within the scope of the following claims. 
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